Как вы знаете, у компании VMware есть программа VMware vExpert, в рамках которой присуждаются награды за особый вклад в развитие технологий виртуализации в плане их пропаганды в медиа-пространстве. Безусловно, компания VMware уделяет особое внимание распространению информационного поля своих продуктов для виртуализации, но не ограничивает ими перспективы получения звания vExpert. Награда vExpert 2012 будет присуждена за деяния, совершенные в прошедшем 2011 году.
Среди профессионалов, получающих данную награду регулярно можно отметить таких известных в сообществе виртуализации людей как Mike Laverick, Eric Sloof, Vladan Seget и многих-многих других блоггеров и евангелистов в сфере виртуализации, которых вы все хорошо знаете. Как всегда, за программу отвечает John Troyer.
В прошлые годы мы с вами взяли номинацию 3 раза - в 2009-м, 2010-м и 2011-м годах. Несколько моих российских и снг-шных коллег также удостаивались этого звания от 1 до 3 раз. В этом году, будем надеяться, круг этих людей расширится.
Надеемся мы не просто так, а вот почему: теперь в программу vExpert внесены существенные изменения и получить почетное звание могут люди, представляющие одну из трех категорий:
Евангелисты (Evangelist Path) - к ним относится ваш любимый автор и другие наши российские коллеги, получившие звания в прошедшие годы. Присуждена эта награда будет как и раньше за активное ведение блогов, разработку утилит и скриптов, участие в публичных мероприятиях и другие вещи, которые способствуют популяризации технологий виртуализации.
Представители заказчиков (Customer Path) - в данной категории окажутся те заказчики, которые внесли наибольший вклад в успех и продвижение продуктов и технологий VMware в информационном пространстве за счет историй успеха, интервью, а также лидерства в сообществах VMware User Groups.
Партнеры VMware (VMware Partner Network Path) - это сотрудники компаний-партнеров VMware, которые внесли вклад в развитие профессиональных сообществ, делились знаниями и пропагандировали технологии виртуализации среди своих коллег по цеху и конечных пользователей.
Несмотря на то, что есть 3 пути к получению награды, сама награда будет для всех, как и раньше, одна.
Если вы знаете кого-то, кто еще не получал этой награды, но, по вашему мнению, достоин ее - напишите об этом мне или в комментариях. Если я согласен с вашем мнением, то я номинирую этого человека от своего имени. К тому же, очень интересно узнать новых людей, сделавших много для виртуализации именно в 2011 году. А то старички все те же - и они уже народу приелись.
Прежде всего, кстати, посмотрите на награды, которые получил продукт vGate R2 не так давно:
Информационно-аналитический центр Anti-Malware провел независимую экспертизу решения vGate R2, в результате которой продукт получил высокую оценку экспертов и вошел в список рекомендуемых продуктов (подробнее)
Продукт vGate R2 стал победителем Конкурса продуктов, организованного ассоциацией Virtualization Security Group Russia в номинации «Контроль доступа» (подробнее)
Продукт vGate R2 удостоен наивысшей награды в категории «Информационная безопасность» отраслевой премии ЗУБР-2011 (подробнее)
Построение комплексной системы обеспечения информационной безопасности в виртуальной среде.
На вебинаре будут рассмотрены особенности построения комплексной системы обеспечения информационной безопасности учитывающей специфику виртуальной среды, а так же особенности приведения виртуальных инфраструктур в соответствие требованиям №152-ФЗ «О персональных данных», СТО БР ИББС и PCI DSS. Будет представлено решение vGate R2.
Вебинары будут интересны всем специалистам, которые работают с виртуальными инфраструктурами или планируют перейти на их использование, а также специалистам по информационной безопасности занимающимся обеспечением их защиты.
Докладчиком на этих вебинарах выступит наша хорошая знакомая - Сидорова Мария, заместитель руководителя направления «Защита виртуальных инфраструктур» компании «Код Безопасности».
Только мы вчера стали развивать тему облачных инициатив VMware, как появился еще один компонент для доступа к облачной инфраструктуре VMware vSphere - VMware vCloud Director Client for iPad.
Как видно из названия, этот клиент, устанавливаемый на iPad, позволяет соединиться с решением vCloud Director конечным пользователям внутреннего облака предприятия или публичного облака сервис-провайдера и самостоятельно выполнять высокоуровневые административные задачи.
Основные возможности vCloud Client for iPad:
Возможность создания новых виртуальных сервисов (наборов виртуальных машин - vApp)
Выполнение простых административных задач (включение-выключение ВМ)
Доступ к консоли отдельных виртуальных машин сервисов vApp посредством сторонних утилит (RDP, VNC, SSH)
Конфигурация среды vCloud Director
Подробнее о возможностях по категориям:
vApp Access and Operations
Редактирование заметок о vApp
Вкл/выкл vApp
Определение и сброс аренды IP-адресов
Базовые настройки по изменению сетевого окружения
Простые изменения конфигурации, касающиеся гостевой ОС
Directly Provision Apps
Создание сервисов vApp из каталога готовых шаблонов (самое нужное)
Развертывание сервисов напрямую из клиента
Inspect and Troubleshoot
Мониторинг выполняющихся или недавно выполненных задач
Отсылка письма с сообщением о причине невыполненной задачи
Remote Desktop Access
Соединение с консолью ВМ посредством RDP, SSH или VNC (совместимость со сторонними клиентами)
Access Your Public/Hybrid Cloud Environment
Вход в облачную инфраструктуру сервис-провайдера с iPad
Возможность создания обращения (тикета) в техническую поддержку сервис-провайдера
Скачать VMware vCloud Director Client for iPad можно по этой ссылке.
По мере возможности мы стараемся рассказывать о новых облачных инициативах различных вендоров, преимущественно VMware, так как, во-первых, эта тема нам ближе, а, во-вторых, только у VMware наблюдается более-менее законченная концепция использования гибридных облаков - комбинации частных (onsite) и публичных (offsite).
Для начала в этой статье мы рассказали о программе VMware Service Provider Program, позволяющей брать виртуальные машины в аренду, которые размещены на серверах сервис-провайдеров. Кстати, чтобы самому стать сервис-провайдером, вы можете обратиться в компанию Softline, являющуюся VSPP-агрегатором, т.е. "дистрибьютором облачных сервисов", через которого происходит взаимодействие с VMware по предоставлению машин в аренду.
На прошлой неделе компания VMware выпустила очередной интересный продукт в линейке облачных сервисов - VMware vCloud Integration Manager. Он позволяет связать клиента и сервис-провайдера средствами веб-фронтенда, автоматизировав некоторые функции сервис-провайдера, которые раньше приходилось выполнять скриптами и вручную. Например, к ним относятся автоматизация развертывания объектов virtual data center, network, account и другие ресурсы, которые заказывает клиент.
VMware vCloud Integration Manager - это прослойка между vCloud Director и порталом для клиентов (веб-сайт) или CRM-системой, которая имеет функции по автоматизации операций:
Но что самое здесь интересное - это Reseller GUI. VMware средствами vCloud Integration Manager предлагает возможности по вынесению функций продаж облачных сервисов (прежде всего, виртуальных машин в аренду) на сторону реселлера. То есть, те сервис-провайдеры, которым лень заморачиваться самостоятельными продажами виртуальных машин поштучно (это ведь влечет за собой высокие операционные затраты) может предоставить реселлеру свой GUI в облаке, средствами которого он сможет самостоятельно развертывать объекты для клиента, как для демо, так и в продакшен, что позволит реселлерам поднять дополнительную денежку из публичных облаков.
Ну а между реселлером и сервис-провайдером заключается договор, по которому часть денег от клиента уходит к реселлеру на базе единовременных выплат или помесячных отчислений. Таким образом, у клиента появляются возможности масштабирования внутреннего и внешнего облака через реселлера, а если нужно только внешнее - то через сервис-провайдера напрямую:
Ну а для оперативного перенесения нагрузки между частным и публичным облаком у клиентов есть средство VMware vCloud Connector, которое представляет собой плагин к vSphere Client и позволяет переносить работающие виртуальные машины в ЦОД сервис-провайдера средствами vCloud API.
На сайте проекта VMware Labs появилась весьма достойная внимания утилита - GUI-плагин к vSphere Client для VMware Auto Deploy. Как вы знаете, среди новых возможностей VMware vSphere 5 появились функции Auto Deploy (только для Enterprise Plus издания), которые позволяют развертывать хост-серверы VMware ESXi по сети через механизм PXE. Это позволяет использовать бездисковые серверы ESXi и проводить массовые развертывания хостов в больших виртуальных инфраструктурах.
Теперь плагин Auto Deploy GUI к vSphere Client позволит настраивать параметры такого развертывания без необходимости использования интерфейса командной строки PowerCLI/PowerShell:
Плагин Auto Deploy GUI весит всего 8 МБ и предоставляет следующие возможности:
Создание и управление профилями образов ESXi (image profiles)
Правила (rules), отражающие мапинг хостов к профилям образов
Поддержка профилей хостов (Host Profiles) для правил, соответствующих профилям образов
Проверка соответствия хостов правилам и приведение в соответствие с ними
Просмотр параметров VIB
Возможность использования стандартных хранилищ образов ESXi и агентов (HA, vCloud), а также сторонних репозиториев
Возможность встраивания пакетов ПО и драйверов
Клонирование сконфигурированного образа
К Auto Deploy GUI идет хороший документ по настройке (без воды - Practical Guide), скачать его можно по этой ссылке. Сам же плагин Auto Deploy GUI можно скачать тут.
Если вам не терпится посмотреть на то, что из себя представляет новая версия настольной ОС Microsoft Windows 8, то есть способ это сделать, не мучая физический компьютер. Если раньше официальная статья KB 2006859 говорила о том, что в виртуальной машине Windows 8 поставить нельзя, то теперь вышел патч для vSphere 5, а William Lam описал способ развертывания гостевой ОС.
Способ очень прост:
1. Устанавливаем на хост VMware ESXi патч ESXi500-201112001 (patch02) из VMware patch repository.
2. Создаем виртуальную машину, указав в качестве гостевой ОС Windows 7 или Windows 2008 R2.
3. Заходим в настройки ВМ "Hardware->Video Card" и включаем "3D graphics support" (нужно для установки VMware Tools).
4. Привязываем к ВМ ISO-образ Windows 8 и запускаем установку.
В итоге Windows 8 в виртуальной машине vSphere 5 работает отлично:
Ну а Windows 8 Developer Preview можно скачать по этой ссылке. Как мы уже писали, бета-версию Windows 8 обещают к концу февраля, а окончательный релиз - к концу года.
Alan Renouf, автор множества полезных скриптов PowerCLI для администрирования инфраструктуры VMware vSphere, выпустил очередное обновление своей бесплатной утилиты vCheck 6.
vCheck 6 - это PowerCLI-скрипт, который готовит отчетность по объектам окружения VMware vSphere и отсылает результат на почту администратора, из которого можно узнать о текущем состоянии виртуальной инфраструктуры и определить потенциальные проблемы.
Пример получаемого отчета можно посмотреть тут (кликабельно):
Вот полный список того, что может выдавать скрипт vCheck 6:
General Details
Number of Hosts
Number of VMs
Number of Templates
Number of Clusters
Number of Datastores
Number of Active VMs
Number of Inactive VMs
Number of DRS Migrations for the last days
Snapshots over x Days old
Datastores with less than x% free space
VMs created over the last x days
VMs removed over the last x days
VMs with No Tools
VMs with CD-Roms connected
VMs with Floppy Drives Connected
VMs with CPU ready over x%
VMs with over x amount of vCPUs
List of DRS Migrations
Hosts in Maintenance Mode
Hosts in disconnected state
NTP Server check for a given NTP Name
NTP Service check
vmkernel warning messages ov the last x days
VC Error Events over the last x days
VC Windows Event Log Errors for the last x days with VMware in the details
VC VMware Service details
VMs stored on datastores attached to only one host
VM active alerts
Cluster Active Alerts
If HA Cluster is set to use host datastore for swapfile, check the host has a swapfile location set
Host active Alerts
Dead SCSI Luns
VMs with over x amount of vCPUs
vSphere check: Slot Sizes
vSphere check: Outdated VM Hardware (Less than V7)
VMs in Inconsistent folders (the name of the folder is not the same as the name)
VMs with high CPU usage
Guest disk size check
Host over committing memory check
VM Swap and Ballooning
ESXi hosts without Lockdown enabled
ESXi hosts with unsupported mode enabled
General Capacity information based on CPU/MEM usage of the VMs
vSwitch free ports
Disk over commit check
Host configuration issues
VCB Garbage (left snapshots)
HA VM restarts and resets
Inaccessible VMs
Плюс ко всему, скрипт имеет расширяемую структуру, то есть к нему можно добавлять свои модули для различных аспектов отчетности по конкретным приложениям. Список уже написанных Аланом плагинов можно найти на этой странице.
Вот эта заметка на блоге VMware напомнила об одной интересной особенности поведения правил совместного и несовместного размещения виртуальных машин на хосте ESX/ESXi (DRS Host Affinity Rules).
Напомним, что для виртуальных машин в класетере DRS можно задавать данные правила для ситуаций, когда требуется определенным образом распределять группы виртуальных машин по хостам или их группам. Требуется это обычно для соблюдения правил лицензирования (см., например, правила лицензирования для ВМ Oracle), когда виртуальные машины могут исполняться только на определенных физических серверах, либо для всяких экзотических ситуаций, когда, к примеру, основную и резервную системут нужно держать на разных хостах.
То есть, мы задаем группы виртуальных машин и хостов:
И указываем, что виртуальные машины DRS-группы могут работать только на данной DRS-группе хостов:
Правила эти бывают мягкими (preferential), когда DRS+HA будут стараться следовать им при штатном функционировании кластера, и жесткими (mandatory, "Must run") - в этом случае ни при каких условиях виртуальные машины не переедут на хосты не из группы. Этого не произойдет ни средствами vMotion/DRS/Maintenance Mode, ни средствами перезапуска HA в аварийных ситуациях.
Для жестких правил есть один интересный аспект: они сохраняются и продолжают действовать даже тогда, когда вы отключили кластер VMware DRS. То есть вы не сможете сделать ручной vMotion или Power On машин на хостах не из группы, а HA не будет их там перезапускать. При этом в настройках кластера с отключенным DRS уже не будет возможности редактирования этих правил (категория VMware DRS пропадет). Это сделано для того, чтобы во время временных сбоев (например, vCenter) лицензионные правила существования ВМ для приложений на хостах не нарушались в любом случае.
Поэтому, если нужно удалить правила, нужно снова включить DRS, удалить их и снова отключить DRS.
Таги: VMware, DRS, Обучение, vSphere, ESX, ESXi, vMotion, HA
Компания VMware объявила о начале поставок новых пакетов лицензий vSphere Acceleration Kit with Management. Это решение наращивает функциональность существующих пакетов VMware vSphere Acceleration Kits с добавлением функций по администрированию виртуальной инфраструктуры средствами новых продуктов. Еще один важный плюс для администраторов vSphere - эти пакеты позволяют бесплатно учиться на курсах VMware, в том числе VCP 5.
С выходом новой версии гипервизора VMware ESXi 5 некоторые старые команды и приемы работы с хост-сервером ушли в прошлое, однако появилось несколько новых трюков, которые мы приведем в этой заметке.
1. Простой способ собрать информацию для обращения в техподдержку VMware.
Теперь можно забрать дамп конфигурации ESXi 5.0 (diagnostic information) для техподдержки прямо из веб-браузера. Для этого в адресной строке просто наберите:
3. Выключить все виртуальные машины хоста ESXi 5.0 одним махом можно командой:
/sbin/poweroffVms
4. Теперь, чтоб не мучиться, есть утилита traceroute (в ESX 4.1 не было). Также есть следующие утилиты: unzip, Sync, pkill, strace, dmesg, ntp-keygen, ntpdc, ntpq.
5. Вместо команды esxcfg-firewall теперь esxcli network firewal. Как пользоваться - написано тут.
Мы уже писали о том, что VMware выпустила плакат для администраторов VMware vSphere 5 по интерфейсу управления инфраструктурой виртуализации PowerCLI через PowerShell, а сегодня очередная порция плакатов с обновленной версией по PowerCLI.
Постер VMware ESXi 5 Reference - основные процедуры администрирования хостов ESXi и виртуальных машин из командной строки.
Продолжаем настаивать на том, что безопасность виртуальных инфраструктур и выполнение при этом требований законодательства по защите персональных данных (ФЗ 152) - вещи архиважные и архинужные. Единственная сегодня возможность реализовать эти 2 вещи правильно - сертифицированный ФСТЭК продукт vGate R2 от компании "Код Безопасности", который автоматически настроит виртуальную инфраструктуру в соответствии с российскими и международными руководящими документами и стандартами (+vSphere 5).
Напомним некоторые особенности защиты персональных данных в виртуальных средах:
В последнее время все больше пользователей виртуализуют критичные базы данных под управлением СУБД Oracle в виртуальных машинах VMware vSphere. При этом есть миф о том, что Oracle не поддерживает свои СУБД в виртуальных машинах, и, если что-то случится, то получить техническую поддержку будет невозможно. Это не так.
Техническая поддержка Oracle для ВМ на VMware vSphere
На самом деле у Oracle есть документ "MyOracleSupport Document ID #249212" в котором прописаны принципы работы с техподдержкой при работе СУБД в ВМ VMware vSphere:
Вкратце их можно изложить так:
1. Действительно, Oracle не сертифицирует работу своих СУБД в виртуальных машинах VMware.
2. Если у вас возникает проблема с БД Oracle в виртуальной машине VMware, то Oracle смотрит, есть ли подобная проблема для физической системы, либо вы можете продемонстрировать, что проблема повторяется на физической машине, а не только в ВМ. Если проблема относится именно к виртуальной машине и не проявляется на физической системе, либо решение от техподдержки Oracle работает только для физического сервера - вас направляют к техподдержке VMware. Однако отметим, что VMware заявляет, что подобных проблем в ее практике еще не было.
Теперь, что касается самой VMware - у них есть отдельная политика технической поддержки "Oracle Support Policy". В ней, в частности, написано, что VMware принимает запросы на техподдержку касательно ВМ Oracle, работающих на vSphere, после чего взаимодействует со службой техподдержки Oracle через TSANet для поиска причины проблемы и решения. Тут важно, что за такие кейсы отвечает сама VMware.
1. Виртуальные машины с СУБД Oracle могут работать на хостах VMware ESX/ESXi, у которых либо все физические процессоры (ядра), либо их часть лицензированы под Oracle. Оптимально, конечно, лицензировать весь хост, однако если это дорого, можно лицензировать и несколько процессоров, после чего привязать конкретные виртуальные машины к физическим процессорам хоста, используя vSphere Client:
Либо используя vSphere Web Client:
Однако, как вы можете прочитать в документе от VMware (см. комментарии к заметке), компания Oracle не признает такого разделения лицензий по процессорам на хосте, хотя сама VMware этим очень недовольна. Поэтому вам придется лицензировать все процессоры хоста, при этом вы там сможете запустить столько экземпляров Oracle, сколько потребуется.
Возможно, эта ситуация в будущем изменится, и можно будет лицензировать отдельные процессоры хоста.
2. Если вы хотите, чтобы виртуальная машина с Oracle перемещалась на другой хост, то все процессоры исходного и целевого хостов должны быть лицензированы Oracle.
3. Что касается кластеров VMware HA/DRS, то тут нужно быть внимательным. Оптимальное решение - это создать отдельный кластер для ВМ с Oracle и лицензировать все процессоры всех хостов в нем, если у вас достаточно виртуальных машин, нагрузки и денег для такой задачи. Если недостаточно - можно лицензировать часть хостов (но, опять-таки, целиком), после чего выставить для них DRS Host Affinity Rules таким образом, чтобы виртуальные машины с Oracle всегда оставались на лицензированных хостах:
Для получения более полной информации о лицензировании Oracle в виртуальной среде VMware vSphere читайте приведенный выше документ.
Мы уже рассказывали про продукт vCenter Operations, который собирает данные о производительности каждого из объектов виртуальной инфраструктуры VMware vSphere (виртуальные машины, хранилища, кластеры, датацентр в целом), хранит их в централизованной базе данных, анализирует их и делает отчет в реальном времени о текущих и потенциальных проблемах производительности.
Теперь этот продукт был существенно доработан: он предоставляет не только средство анализа и решения проблем производительности в датацентре компании, но и средства прогнозирования нагрузки, а также механизмы "осведомленности о приложениях", которые позволяют строить карты зависимости на уровне компонентов приложений для сервисов виртуальной инфраструктуры. Последнее делается средствами специального модуля VMware vCenter Infrastructure Navigator 1.0 (поставляется как виртуальный модуль - Virtual Appliance), который также вышел вместе с vCenter Operations Management Suite.
Ключевые возможности vCenter Operations Management Suite 5.0:
Комбинирование ключевых метрик производительности в общее количество баллов для датацентра (CPU, memory, disk, contention performance).
Отображение основных метрик "самочувствия" виртуальной инфраструктуры и ее эффективности с точки зрения производительности.
vCenter Operations вычисляет диапазон значений, который находится в рамках допустимой производительности, и подсвечивает отклонения от этого диапазона.
Графическое представление инфраструктуры в контексте производительности с возможностью "проваливания" до отдельных компонентов.
Отображение информации об изменениях в иерархии виртуальной инфраструктуры, после чего vCenter Operations показывает, как эти изменения отразились на производительности различных объектов. Например, если виртуальная машина переместилась за счет vMotion между хостами VMware ESX/ESXi, vCenter Operations покажет нам как изменилась нагрузка на хост-серверы.
Обнаружение приложений, работающих в виртуальных машинах, и автоматическое распознавание их компонентов с использованием встроенной базы знаний (Application Component Knowledge Base).
Построение карты взаимосвязей сервисов виртуальной инфраструктуре на уровне корпоративных приложений, которая позволяет осуществлять мониторинг и решение проблем для основных логических компонентов систем, состоящих из нескольких виртуальных машин.
Упрощение создания многомашинных конфигураций vApp для различных подразделений компании + поддержка конфигураций VMware SRM для интегрированного контроля над планами аварийного восстановления.
Как понятно из описанных возможностей, продукт vCenter Operations Management Suite предназначен для крупных виртуальных инфраструктур, где требуется комплексное наблюдение за производительностью и приложениями виртуального датацентра.
Так выглядит Dashboard:
Помните был такой продукт VMware vCenter CapacityIQ? Теперь его больше нет, а его возможности интегрированы в vCenter Operations Suite. Его компоненты отвечают за анализ мощностей датацентра, определение эффективности их использования, а также планирование необходимых мощностей на будущее с учетом трендов загрузки:
Ну и отдельным модулем идет VMware vCenter Infrastructure Navigator 1.0, который отвечает за построение карт сервисов:
vCenter Infrastructure Navigator поставляется как виртуальный модуль в формате OVA и интегрируется в веб-клиент VMware vSphere 5 Web Client в виде плагина, что хорошо, так как не требуется отдельной консоли администрирования. Поддерживается ESX/ESXi 4.0, 4.1 и ESXi 5.0. Скачать vCenter Infrastructure Navigator можно по этой ссылке (для пользователей Operations).
Обзорное видео установки vCenter Infrastructure Navigator:
Использование vCenter Infrastructure Navigator:
Продукт vCenter Operations Management Suite поставляется в 4-х изданиях:
Standard Edition - это стандартное издание продукта, предоставляющее только средства отслеживания производительности и диагностики проблем для небольших окружений.
Advanced Edition - добавляет возможности, пришедшие от продукта CapacityIQ, т.е. аналитика и планирование мощностей инфраструктуры.
Enterprise Edition - добавляются возможности vCenter Infrastructure Navigator и vCenter Chargeback для контроля зависимостей приложений и расчета стоимости виртуальных ресурсов в частных облаках, где производится финансовая оценка стоимости 1 ГГц и 1 МБ выдаваемых пользователям ресурсов.
Enterprise Plus - те же возможности, что и в Enterprise, но добавляются адаптеры к сторонним продуктам мониторинга датацентров, которые могут быть использованы как для виртуальных, так и для физических серверов на различных платформах.
Скачать пробную версию можно по этой ссылке. Отдельно загрузить vCenter Infrastructure Navigator можно тут.
Не так давно мы просили вас ответить на 4 небольших вопроса о миграции на VMware vSphere 5 и используемых хранилищах и гипервизорах. Рады представить вам результаты этого опроса.
1. Оказывается, что большинство из опрошенных уже использует VMware vSphere 5, хотя количество пользователей 4-й версии тоже не так уж и мало:
2. В течение 3-6 месяцев на vSphere 5 перейдет большинство пользователей:
3. В плане хранилищ вперед вырываются агрессивные хапэшники:
Отметим большой потенциал продаж хранилищ под виртуализацию .
4. Несмотря на то, что нас читают в основном пользователи VMware, платформу VMware vSphere используют чуть больше половины опрошенных:
Отметим, что Parallels и Red Hat - использует 3 человека из опрошенных. Подозреваю, что это одни и те же люди :) Шучу.
Напомним, что совсем недавно компания «Код Безопасности» выпустила технический релиз новой версии vGate R2 с поддержкой VMware 5. Сейчас она проходит инспекционный контроль во ФСТЭК для получения соответствующих сертфикатов, наличие которых позволит вашей организации пройти процедуру аттестации или проверки со стороны государственных органов. Сегодня мы более подробно расскажем о новых политиках настройки безопасной среды виртуализации.
Интересное решение попалось на глаза - HotLink SuperVISOR for VMware, продукт, позволяющий в консоли vSphere Client объединить управление платформами и виртуальными машинами VMware vSphere, Microsoft Hyper-V и Citrix XenServer (+KVM от Red Hat). Данное решение позиционируется как комбинированное средство управления гетерогенной инфраструктурой виртуализации:
Работает HotLink SuperVISOR как плагин к vSphere Client, где вы можете увидеть центры управления для гипервизоров гетерогенной среды:
Поскольку Microsoft Hyper-V сейчас набирает обороты, и его присутствие в виртуальной инфраструктуре многих компаний доходит до 25%, подобные решения становятся весьма востребованными, особенно на фоне того, что VMware напрочь отказывается от интеграции своего vCenter со сторонними гипервизорами по очевидным причинам.
Обещают, что продукт HotLink обладает следующими возможностями по гетерогенному управлению по сравнению с другими моделями администрирования:
Практическую демонстрацию продукта SuperVISOR можно увидеть на видео ниже:
Из сайта я не смог понять, когда будет доступно решение HotLink, но сама идея выглядит очень заманчиво и перспективно.
Если вы еще не проводили миграцию на VMware vSphere 5, то нужно обратить внимание на утилиту VMware vCenter Database Pre-Upgrade Checker, которая позволит вам проверить возможность миграции базы данных существующего vCenter 4.0 или 4.1 на новую версию vCenter 5.0. В больших окружениях, где неизвестно, что и как изменялось в БД vCenter данная утилита может оказаться очень актуальной.
Что проверяет VMware vCenter Database Pre-Upgrade Checker:
Различные схемы в БД vCenter
Проверка корректности пользователей и ролей (достаточность привилегий конкретного пользователя на апгрейд)
Проверка структуры таблиц (без проверки данных)
Проверка корректно выставленного режима совместимости (SQL compatibility mode) для Microsoft SQL Server при апгрейде
Перед использованием VMware vCenter Database Pre-Upgrade Checker необходимо сделать следующие вещи:
Pre-Upgrade использует 32-битные dll-ки для разрешения ODBC DSN-ов, поэтому необходимо установить 32-битный пакет JRE/JDK 1.6 update 19 или более поздней версии.
Добавить в переменную PATH на сервере vCenter путь к директории bin для JDK. Для этого идем в Control Panel > System > Advanced system settings > на вкладку Advanced > Environment variables > выбрать System Variables (for all users) или User Variables (for this login user only) > выбрать переменную PATH, после чего нажать Edit (для изменения существующей переменной) и добавляем перед остальными путями строчку (разделитель с уже существующими путями - точка с запятой):
c:\Program Files\java\jdk1.6.0\bin
Убедиться, что для СУБД MS SQL включен протокол TCP/IP. Для этого идем в SQL Configuration Manager -> SQL Server Network Configuration и выбираем "Protocols" для экземпляра БД vCenter.
Теперь запускаем VMware vCenter Database Pre-Upgrade Checker:
Многие из вас уже читали о новой версии StarWind Enterprise 5.8 для организации отказоустойчивых ISCSI-хранилищ для виртуальных машин VMware vSphere и Microsoft Hyper-V. Одна из интересных фич новой версии - возможность резервного копирования хранилищ виртуальных машин, идущая как плагин к продукту (VM Backup). Бэкап работает как для vSphere, так и для Hyper-V (с поддержкой дедупликации).
В связи в этим обновилось сравнение изданий продукта для платформ VMware и Microsoft.
Издания StarWind iSCSI SAN (для серверов ESX / ESXi):
Возможности
StarWind
Enterprise CDP Edition
StarWind iSCSI SAN
1TB
2TB
4TB
8TB
16TB
Unlimited
Support
1 year
1 year
1 year
1 year
1 year
1 year
1 year
# of Servers per license
1
2
2
2
2
4
(2 HA sets)
4
(2 HA sets)
Maximum Capacity
Unlimited
1TB
2TB
4TB
8TB
16TB
Unlimited
# of Concurrent iSCSI Connections
Unlimited
Unlimited
Unlimited
Unlimited
Unlimited
Unlimited
Unlimited
Ethernet ports
Unlimited
Unlimited
Unlimited
Unlimited
Unlimited
Unlimited
Unlimited
Served Disk Drives
Unlimited
Unlimited
Unlimited
Unlimited
Unlimited
Unlimited
Unlimited
Synchronous Mirroring (Active-Active High Availability)
Remote Replication (Active-Passive)
Automatic Failover
Failback with Fast Synchronization
Disk Bridge
SPTI
Image File
IPSec, CHAP, ACL, iSNS
CDP / Snapshots
Thin Provisioning
High Speed Caching
Event Log
Event notifications
Deduplication
*VM Backup Option
$399.00*
$399.00*
$399.00*
$399.00*
$399.00*
$399.00*
$399.00*
Издания StarWind Native SAN for Hyper-V:
Возможности
StarWind Native SAN for Hyper-V
1TB
2TB
4TB
8TB
16TB
Unlimited
Support
1 year
1 year
1 year
1 year
1 year
1 year
# of Servers per license
2
2
2
2
2
2
Maximum Capacity
1TB
2TB
4TB
8TB
16TB
Unlimited
# of Concurrent iSCSI Connections
Unlimited
Unlimited
Unlimited
Unlimited
Unlimited
Unlimited
Ethernet ports
Unlimited
Unlimited
Unlimited
Unlimited
Unlimited
Unlimited
Served Disk Drives
Unlimited
Unlimited
Unlimited
Unlimited
Unlimited
Unlimited
Synchronous Mirroring (Active-Active High Availability)
Remote Replication (Active-Passive)
Automatic Failover
Failback with Fast Synchronization
Disk Bridge
SPTI
Image File
IPSec, CHAP, ACL, iSNS
CDP / Snapshots
Thin Provisioning
High Speed Caching
Event Log
Event notifications
Deduplication
*VM Backup Option
$399.00*
$399.00*
$399.00*
$399.00*
$399.00*
$399.00*
Стоимость VM Backup Option указана за физический сервер ESX или Hyper-V, виртуальные машины которого вы планируете бэкапить. При этом неважно количество процессоров и ВМ на данном сервере.
Как знают многие пользователи VMware, в новой версии платформы VMware vSphere 5 появилась возможность производить "горячую" миграцию виртуальных машин между хостами ESXi сразу по нескольким физическим сетевым адаптерам (Multi NIC vMotion). Опишем кратко особенности использования данной технологии.
При миграции ВМ в vSphere 5 есть следующие особенности:
Поддержка до четырех одновременных миграций на адаптерах 1Gbps и до 8 одновременных миграций по 10Gbps сетевым адаптерам.
Поддержка на хосте ESXi до 4 адаптеров 10Gbps и до 16 адаптеров 1Gbps.
Миграция одной виртуальной машины vMotion может идти сразу по нескольким сетевым адаптерам (между ними просиходит балансировка нагрузки)
В целом, vMotion стала работать быстрее (в подавляющем большинстве случаев, время переключения - не более 1 секунды)
Логи ошибок vMotion стали богаче и информативнее
Миграция vMotion по нескольким сетевым адаптерам - это комплексный процесс, поскольку vSphere приходится обрабатывать различные комбинации из 1 GbE и 10 GbE адаптеров на хостах.
Перед началом vMotion сервер vCenter анализирует сетевые адаптеры на хостах VMware ESX / ESXi и определяет суммарную пропускную способность, которая доступна для миграции. Например, если у хоста 2 адаптера 1GbE и 1 адаптер 10GbE, тогда пул хоста считается равным 12 GbE. Емкость пула определяется как на исходном, так и на целевом хосте.
Далее есть несколько аспектов работы vMotion:
Если исходный и целевой хосты имеют адаптеры 1GbE NIC, то между ними настраивается одно соединение для vMotion.
Если исходный хост имеет 3 адаптера 1GbE NIC, а целевой хост имеет 1 адаптер 10GbE, то с исходного хоста к целевому, в его адаптер, открывается 3 параллельно работающих соединения (сокета vMotion).
Если исходный хост имеет 15 адаптеров 1GbE, а целевой - 1 адаптер 10GbE и 5 адаптеров 1GbE, то первые 10 адаптеров исходного хоста соединяются с одним 10GbE-адаптером целевого, а дальше 5 адаптеров 1GbE соединяются на исходном и целевом хостах между собой. Таким образом, для миграций (одной или нескольких) открыто суммарно 15 соединений.
Ну и, само собой, если на исходном хосте 2 адаптера 1GbE, а на целевом только один такой адаптер, то будет открыто только одно соединение 1GbE.
При всех этих моментах нужно помнить про ограничения из первого списка. Ну и напоследок видео про настройку vMotion по нескольким сетевым адаптерам:
Наконец-то Forbes Guthrie выпустил самую известную "шпаргалку" по администрированию платформы VMware vSphere 5 - Reference Card. На этом плакате A4 из двух страниц собраны самые нужные команды и теоретическая информация для администраторов VMware, касающаяся хостов ESXi, сервера управления vCenter, виртуальных машин, хранилищ, сетей и т.п.:
Этот документ может оказаться очень полезным при подготовке к экзамену на сертификацию VMware Certified Professional 5 (VCP5). Кстати о VCP5 - для тех, кто имеет сертификат VCP4, осталось совсем немного времени для сдачи экзамена без прохождения курса VMware vSphere: What's New [V5.0] (за немалые деньги, кстати). А именно - сдать нужно до 29 февраля.
В данной статье объединены все общедоступные на сегодняшний день расширенные настройки кластера VMware HA (с учетом нововведений механизма) для обеспечения высокой доступности сервисов в виртуальных машинах VMware vSphere 5.0 и более ранних версий. Отказоустойчивость достигается двумя способами: средствами VMware HA на уровне хостов ESXi (на случай отказов оборудования или гипервизора) и средствами VMware VM Monitoring (зависание гостевой операционной системы).
На каждом хосте службой VMware HA устанавливается агент Fault Domain Manager (FDM), который пришел на смену агентам Legato AAM (Automated Availability Manager). В процессе настройки кластера HA один из агентов выбирается как Master, все остальные выполняют роль Slaves (мастер координирует операции по восстановлению, а в случае его отказа выбирается новый мастер). Теперь больше нет primary/secondary узлов. Одно из существенных изменений VMware HA - это Datastore Heartbeating, механизм, позволяющий мастер-серверу определять состояния хост-серверов VMware ESXi, изолированных от сети, но продолжающих работу с хранилищами.
Задать Advanced Options для VMware HA (иногда их называют Advanced Settings) можно, нажав правой кнопкой на кластер в vSphere Client и далее выбрав пункт "Edit Settings", где уже нужно вводить их как указано на картинке:
Список Advanced Options для VMware HA, действующих только в vSphere 5.0:
das.ignoreinsufficienthbdatastore - определяет, будет ли игнорировано сообщение о количестве имеющихся Heartbeat-хранилищ, которое меньше сконфигурированного в настройке das.heartbeatdsperhost (по умолчанию - это 2 хранилища). То есть если Heartbeat-хранилище присутствует только одно - будет выведено следующее сообщение:
Выставление значения этого параметра в true уберет это предупреждение из vSphere Client.
das.heartbeatdsperhost - определяет количество Heartbeat-хранилищ, которое можно регулировать данной настройкой (допустимые значения - от 2 до 5). По умолчанию, данное значение равно 2.
das.config.log.maxFileNum - определяет количество лог-файлов, в пределах которого будет происходить их ротация.
das.config.log.maxFileSize - максимальный размер лог-файла, задаваемый в байтах.
das.config.log.directory - путь для хранения лог-файлов VMware HA. При задании настроек логов следует руководствоваться следующей таблицей (подробнее читайте тут на последних страницах):
das.config.fdm.deadIcmpPingInterval - интервал между пингами по протоколу ICMP для определения доступности Slave-хоста ESXi в сети со стороны Master, в случае, если нет коммуникации с FDM-агентом Slave-хоста (используется, чтобы определить - сломался агент FDM или хост вышел из строя). По умолчанию задано значение 10 (секунд).
das.config.fdm.icmpPingTimeout - таймаут, который хост (мастер) ожидает перед получением ответа на пинг, при неполучении которого он считает один из хостов недоступным из сети (то есть время, которое он дает для ответа на пинг, после чего начинаются операции по восстановлению ВМ). По умолчанию задано значение 5 (секунд).
das.config.fdm.hostTimeout - таймаут, который мастер ожидает после события неполученного хартбита от FDM-агента хоста после чего он определяет является ли хост отказавшим (dead), изолированным (isolated) или в другом сегменте разделенной сети (partitioned). По умолчанию задано значение 10 (секунд). Сами же хартбиты между мастером и slave-хостами посылаются каждую секунду.
das.config.fdm.stateLogInterval - частота записи состояния кластера в лог-файл. По умолчанию выставлено в 600 (секунд).
das.config.fdm.ft.cleanupTimeout - когда сервер vCenter инициирует запуск Secondary-машины, защищенной с помощью Fault Tolerance, он информирует мастера HA о том, что он начал этот процесс. Далее мастер ждет время, выставленное в этой настройке, и определяет запустилась ли эта виртуальная машина. Если не запустилась - то он самостоятельно инициирует ее повторный запуск. Такая ситуация может произойти, когда во время настройки FT вдруг вышел из строя сервер vCenter. По умолчанию задано значение 900 (секунд).
das.config.fdm.storageVmotionCleanupTimeout - когда механизм Storage vMotion перемещает виртуальную машину с/на хосты ESX 4.1 или более ранней версии, может возникнуть конфликт, когда HA считает, что это не хранилище ВМ переместилось, а сама ВМ отказала. Поэтому данная настройка определяет, сколько времени мастеру нужно подождать, чтобы завершилась операция Storage vMotion, перед принятием решения о перезапуске ВМ. См. также нашу заметку тут. По умолчанию задано значение 900 (секунд).
das.config.fdm.policy.unknownStateMonitorPeriod - определяет сколько агент мастера ждет отклика от виртуальной машины, перед тем как посчитать ее отказавшей и инициировать процедуру ее перезапуска.
das.config.fdm.event.maxMasterEvents - определяет количество событий, которые хранит мастер операций HA.
das.config.fdm.event.maxSlaveEvents - определяет количество событий, которые хранят Slave-хосты HA.
Список Advanced Options для VMware HA в vSphere 5.0 и более ранних версиях:
das.defaultfailoverhost- сервер VMware ESXi (задается короткое имя), который будет использоваться в первую очередь для запуска виртуальных машин в случае сбоя других ESXi. Если его емкости недостаточно для запуска всех машин – VMware HA будет использовать другие хосты.
das.isolationaddress[n] - IP-адрес, который используется для определения события изоляции хостов. По умолчанию, это шлюз (Default Gateway) сервисной консоли. Этот хост должен быть постоянно доступен. Если указано значение n, например, das.isolationaddress2, то адрес также используется на проверку события изоляции. Можно указать до десяти таких адресов (диапазон n от 1 до 10).
das.failuredetectioninterval - значение в миллисекундах, которое отражает время, через которое хосты VMware ESX Server обмениваются хартбитами. По умолчанию равно 1000 (1 секунда).
das.usedefaultisolationaddress - значение-флаг (true или false, по умолчанию - true), которое говорит о том, использовать ли Default Gateway как isolation address (хост, по которому определяется событие изоляции). Параметр необходимо выставить в значение false, если вы планируете использовать несколько isolation-адресов от das.isolationaddress1 до das.isolationaddress10, чтобы исключить шлюз из хостов, по которым определяется событие изоляции.
das.powerOffonIsolation - значение флаг (true или false), используемое для перекрытия настройки isolation response. Если установлено как true, то действие «Power Off» - активно, если как false - активно действие «Leave powered On». Неизвестно, работает ли в vSphere 5.0, но в более ранних версиях работало.
das.vmMemoryMinMB - значение в мегабайтах, используемое для механизма admission control для определения размера слота. При увеличении данного значения VMware HA резервирует больше памяти на хостах ESX на случай сбоя. По умолчанию, значение равно 256 МБ.
das.vmCpuMinMHz - значение в мегагерцах, используемое для механизма admission control для определения размера слота. При увеличении данного значения VMware HA резервирует больше ресурсов процессора на хостах ESX на случай сбоя. По умолчанию, значение равно 256 МГц (vSphere 4.1) и 32 МГц (vSphere 5).
das.conservativeCpuSlot - значение-флаг (true или false), определяющее как VMware HA будет рассчитывать размер слота, влияющего на admission control. По умолчанию установлен параметр false, позволяющий менее жестко подходить к расчетам. Если установлено в значение true – механизм будет работать как в VirtualCenter 2.5.0 и VirtualCenter 2.5.0 Update 1. Неизвестно, осталась ли эта настройка актуальной для vSphere 5.0.
das.allowVmotionNetworks - значение-флаг, позволяющее или не позволяющее использовать физический адаптер, по которому идет трафик VMotion (VMkernel + VMotion Enabled), для прохождения хартбитов.Используется только для VMware ESXi. По умолчанию этот параметр равен false, и сети VMotion для хартбитов не используются. Если установлен в значение true – VMware HA использует группу портов VMkernel с включенной опцией VMotion.
das.allowNetwork[n] – имя интерфейса сервисной консоли (например, ServiceConsole2), который будет использоваться для обмена хартбитами. n – номер, который отражает в каком порядке это будет происходить. Важно! - не ошибитесь, НЕ пишите das.allowNetworkS.
das.isolationShutdownTimeout - значение в секундах, которое используется как таймаут перед срабатыванием насильственного выключения виртуальной машины (power off), если не сработало мягкое выключение из гостевой ОС (shutdown). В случае выставления isolation response как shutdown, VMware HA пытается выключить ее таким образом в течение 300 секунд (значение по умолчанию). Обратите внимание, что значение в секундах, а не в миллисекундах.
das.ignoreRedundantNetWarning - значение-флаг (true или false, по умолчанию false), который при установке в значение false отключает нотификацию об отсутствии избыточности в сети управления («Host xxx currently has no management network redundancy»). По умолчанию установлено в значение false.
Настройки VM Monitoring для VMware HA платформы vSphere 5.0 и более ранних версий:
das.vmFailoverEnabled - значение-флаг (true или false). Если установлен в значение true – механизм VMFM включен, если false – выключен. По умолчанию установлено значение false.
das.FailureInterval - значение в секундах, после которого виртуальная машина считается зависшей и перезагружается, если в течение этого времени не получено хартбитов. По умолчанию установлено значение 30.
das.minUptime - значение в секундах, отражающее время, которое дается на загрузку виртуальной машины и инициализацию VMware Tools для обмена хартбитами. По умолчанию установлено значение 120.
das.maxFailures - максимальное число автоматических перезагрузок из-за неполучения хартбитов, допустимое за время, указанное в параметре das.maxFailureWindow. Если значение das.maxFailureWindow равно «-1», то das.maxFailures означает абсолютное число отказов или зависаний ОС, после которого автоматические перезагрузки виртуальной машины прекращаются, и отключается VMFM. По умолчанию равно 3.
das.maxFailureWindow - значение, отражающее время в секундах, в течение которого рассматривается значение параметра das.maxFailures. По умолчанию равно «-1». Например, установив значение 86400, мы получим, что за сутки (86400 секунд) может произойти 3 перезапуска виртуальной машины по инициативе VMFM. Если перезагрузок будет больше, VMFM отключится. Значение параметра das.maxFailureWindow может быть также равно «-1». В этом случае время рассмотрения числа отказов для отключения VMFM – не ограничено.
Настройки, которые больше не действуют в vSphere 5.0:
das.failuredetectiontime
Работает только в vSphere 4.1 и более ранних версиях (см. ниже).
Раньше была настройка das.failuredetectiontime - это значение в миллисекундах, которое отражает время, через которое VMware HA признает хост изолированным, если он не получает хартбитов (heartbeats) от других хостов и isolation address недоступен. После этого срабатывает действие isolation response, которое выставляется в параметрах кластера в целом, либо для конкретной виртуальной машины. По умолчанию, значение равно 15000 (15 секунд). Рекомендуется увеличить это время до 60000 (60 секунд), если с настройками по умолчанию возникают проблемы в работе VMware HA. Если у вас 2 интерфейса обмена хартбитами - можно оставить 15 секунд.
В VMware vSphere 5, в связи с тем, что алгоритм HA был полностью переписан, настройка das.failuredetectiontime для кластера больше не акутальна.
Теперь все работает следующим образом (см. также новые das-параметры, которые были описаны выше).
Наступление изоляции хост-сервера ESXi, не являющегося Master (т.е. Slave):
Время T0 – обнаружение изоляции хоста (slave).
T0+10 сек – Slave переходит в состояние "election state" (выбирает "сам себя").
T0+25 сек – Slave сам себя назначает мастером.
T0+25 сек – Slave пингует адрес, указанный в "isolation addresses" (по умолчанию, это Default Gateway).
T0+30 сек – Slave объявляет себя изолированным и вызывает действие isolation response, указанное в настройках кластера.
Наступление изоляции хост-сервера ESXi, являющегося Master:
T0 – обнаружение изоляции хоста (master).
T0 – Master пингует адрес, указанный в "isolation addresses" (по умолчанию, это Default Gateway).
T0+5 сек – Master объявляет себя изолированным и вызывает действие isolation response, указанное в настройках кластера.
Как мы видим, алгоритм для мастера несколько другой, чтобы при его изоляции остальные хосты ESXi смогли быстрее начать выборы и выбрать нового мастера. После падения мастера, новый выбранный мастер управляет операциями по восстановлению ВМ изолированного хоста. Если упал Slave - то, понятное дело, восстановлением его ВМ управляет старый мастер. И да, помним, что машины будут восстанавливаться, только если в Isolation Responce стоит Shutdown или Power Off, чтобы хост мог их погасить.
das.bypassNetCompatCheck
Работает только в vSphere 4.1 и более ранних версиях (см. ниже).
Это значение-флаг (true или false, по умолчанию false), который будучи установлен в значение true позволяет обойти дополнительную проверку на совместимость с HA. В VirtualCenter Update 2 была введена проверка на совместимость подсетей, по которым ходят хартбиты. Возникала ошибка: «HA agent on in cluster in has an error Incompatible HA Network: Consider using the Advanced Cluster Settings das.allowNetwork to control network usage». Теперь, если сети считаются несовместимыми с точки зрения HA, однако маршрутизируемыми – новая опция поможет осуществить корректную настройку кластера.
Таги: VMware, HA, FDM, VMachines, ESXi, Обучение, vSphere
Для тех пользователей, кто только начинает свое знакомство с технологиями виртуализации, первым серверным гипервизором в большинстве случаев становится VMware ESXi. В этой статье мы приведем пошаговую инструкцию по получению лицензионного ключа на беcплатную платформу виртуализации VMware ESXi, которая официально называется VMware vSphere Hypervisor.
Если вы обновляли хосты VMware vSphere 4.1 на vSphere 5.0, то у вас может возникнуть ошибка "Operation timed out" при переходе хост-сервера ESXi 5.0 в состояние "Election", т.е. выбора мастера операций (см. нашу статью о VMware HA в vSphere 5.0).
Когда инициируется запрос "start" для FDM, агент не запускается и HA пытается переустановить его, что также заканчивается неудачно, поскольку он имеет правильную версию и вроде как установлен нормально. Однако HA в этом случае не работает. Детали вы найдете вот в этой ветке на VMTN.
Это очередное доказательство той мысли, которую мы доносим с выходом каждой новой мажорной версии vSphere - никогда не делайте апгрейд на новую версию, а всегда переустанавливайте хост-серверы ESXi (потому что баги выползают буквально с каждым релизом).
Для решения проблемы нужно сделать следующее:
Перевести хост в режим обслуживания (Maintenance Mode) и убрать с него все ВМ.
Скопировать файл /opt/vmware/uninstallers/VMware-fdm-uninstall.sh куда-нибудь во временную папку (например, /tmp)
Из приведенной выше папки (/tmp) запустить скрипт ./VMware-fdm-uninstall.sh
Будет небольшая задержка на выполнение скрипта.
Вывести хост из Mainenance Mode и на панели "Recent Tasks" убедиться, что vCenter начал переустановку агента.
Это, по-идее, должно помочь. Ну и не забывайте, что все логи VMware HA на хосте (а именно, FDM-агента) хранятся в файле var/log/fdm.log.
Очень полезной может оказаться не только указанная ветка Community, но и статья KB 2004429.
Update: проблема оказывается серьезнее - она касается также ситуации, когда вы просто накатили патчи на ESXi 5.0 (см. комментарии).
Таги: VMware, HA, Bugs, Bug, vSphere, ESXi, Upgrade
Если у вас в инфраструктуре несколько версий VMware vSphere (например, 4.1 и 5.0) или вы хотите поставить VMware Tools для тестирования или на старых серверах (хотя все VMware Tools можно скопировать с ESX напрямую), вам может оказаться полезной вот эта ссылка - http://packages.vmware.com/tools/esx/index.html.
Там все упорядочено по версиям VMware vSphere / ESX / ESXi:
Последняя версия VMware Tools находится в папке "latest". По свойствам папки легко обнаружить дату обновления.
Ну а на сервере VMware ESXi пакеты VMware Tools находятся тут - /vmimages/tools-isoimages/. Скопировать вы их можете с помощью Veeam FastSCP.
Ну и видео обновления VMware Tools - мало ли кому-то пригодится:
Как вы знаете, согласно многим исследованиям, да и по фактической ситуации - VMware на сегодняшний день является безусловным лидером в сегменте платформ виртуализации. Согласно оценкам различных аналитических компаний, ей принадлежит 70-90% реального рынка серверной виртуализации (будем здесь говорить о коммерческих продуктах, которые имеют перспективы по внедрению на предприятиях, а не бесплатные поделки "на поиграться").
Но наш прогноз на 2012 год (и не только наш, кстати) - VMware существенно утратит лидерство в сегменте серверной виртуализации. И тому есть несколько причин:
1. Конкуренты продукта VMware vSphere (а именно, ближайший - Microsoft Hyper-V) взрослеют. Достаточно лишь взглянуть на список новых возможностей Hyper-V 3.0, чтобы понять, что гипервизор Microsoft очень и очень близко подобрался к платформе VMware. Теперь у MS есть не только возможности, покрывающие СМБ-сегмент, но и некоторые Enterprise-функции (например, Storage Live Migration).
2. Ценовая и лицензионная политика VMware существенно огорчила многих пользователей в этом году с выходом VMware vSphere 5. Изменения в лицензировании, касающиеся использования оперативной памяти, уже не заставляют пользователей использовать все более мощное оборудование для максимального "отжима" стоимости купленных лицензий на стоимости владения. Особенно россиян не порадовала в 2011 году политика одностороннего увеличения цен на продукты на 20% без какого-либо диалога или комментариев со стороны российского представительства VMware. Точнее даже не так - комментарии были в стиле: "А кто мы? Мы - никто. Что говорят, то и делаем". Ответ, честно говоря, совсем не деловой. Ну а ценовая политика на Hyper-V+SC VMM для многих выглядит значительно привлекательнее (тем более, что в СМБ стоимость владения считают нечасто).
3. VMware фокусируется на других задачах, а именно - облачных вычислениях. Понятное дело, что мир меняется, тренды возникают другие. Пользователям хочется "каких-то облаков". Разговоров много, поэтому приходится и вступать в альянс с SalesForce, и выпускать целую линейку "облачных" продуктов, таких как vCloud Director, усиливать инициативы VSPP и прочее. Все это сдвигает маркетинговые бюджеты и технические инициативы в другую сферу, что неизбежно ведет к потере фокуса на платформе, которая изжила уже, по-сути, все перспективы своего развития.
4. VMware почти ничего не делает для СМБ, отдавая, по-сути, этот рынок Microsoft. Выпуск таких продуктов, как vSphere Storage Appliance хоть и является каким-то шагом, но ничего не меняет концептуально - для небольших компаний vSphere как была дорогим продуктом, так и осталась. Здесь нам видится четкая установка на ухватывание жирных кусков в Enterprise, без какой-либо определенной позиции на рынке в целом. Подтверждением тому является неготовность VMware во многих случаях идти на компромисы в тех случаях, когда раньше она соглашалась на них идти (это приходится слышать не только от наших, но и от зарубежных коллег). Что изменилось-то? Зазнались?
5. Рынок серверной виртуализации уже постепенно приходит к насыщению и выходит на режим регулярных продаж и торговли контрактами поддержки, а не "прорывных" инициатив. Ни для кого не секрет, что продление контрактов поддержки почти ничего не приносит интеграторам, а значит и не рождает их активности. В этом плане у конкурентов VMware есть реальные возможности по "переключению" пользователей на свои продукты с хорошей маржой для партнеров и большими откатами для заказчиков.
Ну и глянем на результаты последних исследований V-Index от компании Veeam Software.
2-й квартал 2011 года:
Тут уже видно, что VMware несколько сдает позиции. А вот тут пишут, что 38% компаний задумываются о смене гипервизора для серверной виртуализации. Среди причин они назвали: высокую стоимость платформы (58,9%), возможности других гипервизоров (47,4%), модель лицензирования (46,8%) и повышение "зрелости" альтернативных продуктов (41,6%).
Так что в 2012 году нас ждут перемены в сегменте серверной виртуализации. Тем более, что темпы роста рынка давно уже сильно замедлились. Но дело еще и в том, что сам рынок меняется - с облаков можно грести еще большие деньги, надо только найти правильный подход. Вон - посмотрите на стоимость VMware vCloud Director. Если он будет продаваться хорошо - то, может, у VMware получится оставаться на гребне волны. Но уж слишком много сейчас появляется альтернатив...
Ни для кого не секрет, что следующий год для технологий виртуализации станет годом облачной инфраструктуры. Многие вендоры, сервис-провайдеры и интеграторы обещают пользователям "золотые горы", предлагая облачные услуги различного характера (SaaS, PaaS и IaaS), построенные на базе самых разных архитектур.
VMware в этом плане также старается не отставать, предлагая свои фреймворки, описывающие архитектуру частных и публичных облаков, построенных на продуктах VMware vSphere, vCloud Director, Request Manager и прочих. Одним из таких фреймворков является vCat - vCloud Architecture ToolKit.
В рамках документов, предлагаемых в составе vCat, вы найдете не только детальное описание архитектуры облачной среды, построенной на базе ПО VMware, но и конкретные примеры развертывания частного или публичного облака. Вот, собственно, сами документы:
Document Map – Document descriptions, function, and table of contents.
vCAT Introduction – Considerations when first developing your Cloud strategy.
Скачав эту утилиту совершенно бесплатно, вы узнаете, насколько ваша виртуальная инфраструктура соответствует следующим общепринятым нормам обеспечения безопасности виртуальной среды:
vGate Compliance Checker for VMware vSphere 5 и VMware vSphere 4.1 New!
PCI DSS 2.0
VMware Security Hardening Best Practices 4.1
CIS VMware ESX Server Benchmarks 4
vGate Compliance Checker for VMware Infrastructure и VMware vSphere 4
PCI DSS 1.2
VMware Security Hardening Best Practices 4
CIS VMware ESX Server Benchmarks 3.5
Отчет будет выглядеть примерно так:
То есть для каждого несоответствия нормам безопасности вам не только расскажут о самом факте, но и дадут ссылку на соответствующий пункт регламентирующего документа. Для многих компаний это будет весьма полезно - узнать, сколько у них потенциальных проблемных мест в сфере ИБ для инфраструктуры виртуализации.
Интересное (но неофициальное) исследование на тему миграции на новую версию платформы VMware vSphere 5 опубликовано на блоге virtualgeek. Было опрошено 1935 респондентов. Напомним, что VMware vSphere 5 вышла в августе этого года.
Самый занимательный график - это ответы на вопрос "Какую версию VMware vSphere вы сейчас используете?" (допускалось более одного варианта ответа):
59,2% для vSphere 5 - это очень и очень большой показатель, учитывая выход продукта 4 месяца назад.
Полезен также график ответов на вопрос "Используете ли вы другие технологии виртуализации":
Ну Hyper-V понятно, но, фигасе, XenServer жжет. Неожиданно.
Далее вопрос о проценте виртуализованных серверов (но надо учитывать специфику исследования - отвечали люди, которые крутятся в сфере виртуализации). График в лучших традициях Чурова, но автор говорит, что результат где-то 86%.
Далее - тоже интереснейшая тема. Системы хранения каких вендоров используют под виртуализацию:
EMC на высоте - молодцы. Но, по-моему, автор из EMC, поэтому тоже надо на это делать скидку.
Ну и теперь - ответьте на вопросы для нашего небольшого исследования:
Вот тут те же IDC пишут, что к Virtualization 3.0 развитый мир придет не раньше 2013 года, а главными ее признаками будут полностью виртуализованный ЦОД, объединяющий сервисы собственного внутреннего облака и внешних облаков сервис-провайдеров, адаптивная инфраструктура (если проще - то самооптимизирующаяся) и сервисно-ориентированная бизнес-модель.
Вообще, это интересная штука - классификация зрелости виртуализации по верисям - Virtualization 1.0, 2.0 и 3.0. Если кратко, то эти этапы, с точки зрения признаков, преимуществ и используемых технологий, на примере VMware я бы охарактеризовал так:
Virtualization 1.0 - консолидация
Аудит собственной инфраструктуры физических серверов
Выбор платформы - базовая консолидация серверов (низкая и средняя критичность)
Экономия капитальных и операционных затрат (серверы, электричество), но больший фокус на капитальных
Быстрый экспансивный рост виртуальной инфраструктуры (зачастую, бесконтрольный)
Применение разнородных скриптов и стороннего ПО для решения специфических задач
Virtualization 2.0 - управление
Унификация развертывания новых серверов в виртуальных машинах (то есть, запрос на создание сервера формируется в виде вычислительных ресурсов и хранилища - без привязки к оборудованию). Автоматизация процессов выделения ВМ пользователям
Фокус на операционных затратах (сокращение издержек на управление, обслуживание, мониторинг, резервное копирование и т.п.) и отдаче от возможностей ПО виртуализации (интенсификация, увеличение коэффициента консолидации)
Внедрение новых средств управления виртуальной средой (мониторинг, отчетность, интеграция с существующим ПО для управления датацентром)
Унификация процедур управления: обновлений, настройки конфигурации хостов и ВМ, шаблоны рабочих процессов (например, VMware Orchestrator, Host Profiles, запланированные задачи и т.п.)
Управляемое планирование мощностей виртуальной среды (Capacity Planning)
Построение модели TCO/ROI дл виртуальной инфраструктуры (сколько обходится ее содержание и как окупаются инвестиции)
Внедрение специализированных средств обеспечения безопасности
Первые производственные внедрения VDI-инфраструктуры (для наименее критичных пользователей)
Расширенные сервисы по отказо- и катастрофоустойчивости инфраструктуры (например, VM Monitoring и VMware SRM + план восстановления после сбоев, репликация ВМ)
Расширенные сервисы управления ресурсами (например, VMware Net I/O Control, Storage I/O Control, DPM и т.п.)
Расширенные сервисы мобильности (Storage vMotion+vMotion между ЦОД, распространение виртуализованных приложений в виде пакетов, Offline Desktops для VDI)
Расширенные сервсиы хранилищ (VMware Storage DRS, профили хранилищ, ярусное хранение данных серверов и виртуальных ПК, VAAI)
Унификация средств решения рутинных задач (например, VMware PowerShell/PowerCLI, Orchestrator)
Первые опыты по формализации внутреннего облака (постоянный учет затрат, соглашения SLA внутри компании, выдача ресурсов по требованию, обслуживание жизненного цикла ВМ)
Первые опыты по использованию сервисов публичных облаков
Virtualization 3.0 - самооптимизация и услуги для бизнеса
Виртуализация Tier 1 систем (самая высокая критичность)
Полная автоматизация операций по управлению виртуальной средой, внедрение средств самооптимизации вычислительных ресурсов, сетей и хранилищ
Унификация использования адаптивных сервисов (например, Storage DRS, SIOC и т.п.)
План для всех видов отказов и простоев в виртуальной инфраструктуре - оформление SLA для пользователей (доступность, производительность и т.п.)
Делегирование части полномочий "повзрослевшим" пользователям (выдача ресурсов по требованию самому себе, порталы самообслуживание, средства управления и контроля)
Непрерывный учет затрат (например, VMware Chargeback), четкое представление о том, сколько стоит 1 МБ и 1 ГГц для соответствующего SLA или Tier, т.е. любая создаваемая ВМ.
Интеграция и федерация (сведение в одну точку управления) средств управления и мониторинга физической и виртуальной среды (от уровня приложений до уровня ЦОД)
Гетерогенные среды виртуализации (например, где-то Hyper-V будет использовать выгоднее, чем VMware с точки зрения TCO) + единые средства управления такими средами
Виртуализация хранилищ SAN (например, EMC VPLEX + интеграция с виртуальной средой)
VDI как стандарт настольных ПК в организации (доставка ПК, клиентский гипервизор + доставка в них виртуализованных приложений) - этот момент, кстати, спорный, т.к. может быть заменен альтернативной облачной концепцией
Оформление внутреннего облака предприятия (учет мощностей и денег, SLA, ITaaS, уровни доступности, классы обслуживания и т.п.) + возможности предоставления услуг внешним организациям, а также аффилированным или дочерним компаниям (зависит от специфики организации)
Расширение использования внешних облаков (SaaS+PaaS+IaaS), механизмы использования ресурсов внешнего облака по требованию
RSS
